Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pip-ipit-transition-00.txt < prev next >

Wrap

Text File | 1993-07-08 | 39.1 KB | 983 lines

Pip Working Group P. Francis INTERNET-DRAFT (formerly Tsuchiya) Bellcore July 1993 IP Independent Transition (IPIT) for Pip Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document outlines a transition scheme for moving from IP to Pip. While this document discusses Pip in particular, it could be applied to any IPng. The transition scheme discussed here is called IPIT, for IP Independent Transition. It has been developed to address problems with the IPAE transition scheme, after which the previous Pip transition scheme was based. The shortcomings of IPAE stem from its reliance on IP addresses dur- ing the first phases of transition. The result is that IP-only hosts will not be able to talk globally to IPng hosts after IP addresses have depleted (they will only be able to talk intra-domain). IPIT allows new Pip systems to talk to IP systems without a globally unique IP address. As a result, IP address depletion is less likely with IPIT, and IP-only hosts will be able to talk to Pip hosts for- ever. In this sense, IPIT is as much a co-existence scheme as it is a transition scheme. Pip WG, Expires February 1, 1994 [Page 1] INTERNET-DRAFT Pip Transition July 1993 1. Problems with IPAE I have increasing concerns about IPAE-style transition. There are some aspects of it that are bad for Pip in particular, but I also have a general concern. That is, for ubiquitous global packet exchange, the transition requires that the large majority of systems are IPng systems at the point in time when IP addresses are no longer unique. When IP addresses are no longer unique, then IPng systems, at least for the purpose of inter-domain communications, are config- ured without globally unique IP addresses. Without a globally unique IP address, an IPng system cannot talk to an IP-only systems in other domains, because the IP-only system has no way to uniquely identify the IP-only system [1]. If there are very few IP-only systems by the time IP addresses are no longer unique, then the problem is not so bad. I am concerned, how- ever, that it will take the community a very long time to really install IPng. Even with address depletion as a motivating factor towards IPng, it may be that users will choose to do NAT or address reuse rather than install IPng. I am also concerned that the need for IP address assignments in new systems will do nothing to slow the depletion of IP addresses. IPAE-style transition additionally has some bad ramifications for Pip specifically. Having to assign IP addresses to Pip hosts constrains them in several ways. First, the auto-address configuration feature of Pip is less advantageous if an IP address must be manually assigned to the host. Plug-and-play operation is lost. Second, the IPAE scheme implies that packets from an IP host to a Pip host are routed via IP until they happen to reach a Pip router. When the infrastructure is still primarily IP (with a Pip overlay), this will mean that IP packets from IP hosts will travel as IP for most of the path, and are therefore subject to the same limitations as IP. This manifests itself as limiting mobility and limiting provider selection. In our Columbus demo, we realized that we could only achieve one-direction provider selection with IPAE, because the return packets would take the IP path regardless of the path taken by the forward (Pip) packet. When considering demo'ing mobility for the Amsterdam demo, we discovered that the movement from one LAN to another would require a new IP address, and therefore a new Pip ID. Thus, mobility in Pip over the near term is only as good as mobility with IP, which is not very good. Pip WG, Expires February 1, 1994 [Page 2] INTERNET-DRAFT Pip Transition July 1993 So, for all of the above reasons, I am beginning to favor a transi- tion scheme that does not require an IP address in the Pip header. I call the scheme IP Independent Transition, or IPIT. IPIT is more complex algorithmically than IPAE, but I think it is not overly com- plex. In any event, IPIT has the advantage of immediately freeing Pip from the constraints and limitations of IP. 2. Description of IPIT IPIT has the following characteristics: 1. Pip hosts do not need IP addresses embedded in them. (By-and- large this document assumes that Pip is the IPng being transi- tioned to. However, IPIT can be applied to any IPng transition scheme.) 2. Unlike IPAE, IPIT potentially allows IP hosts to remain IP for- ever, without losing the ability to communicate directly with all other hosts, either IP or IPng. I say potentially because this is only possible as long as the number of IP-only hosts is small enough that IP address depletion doesn't occur. Since IPng hosts don't require IP addresses, however, this happen- stance is a distinct possibility. In this sense, IPIT is as much a co-existence scheme as it is a transition scheme. 3. In general, packet translation takes place as close to the IP host as possible, but at distinct locations, usually a router on the subnet of the host or a router at the border of the host's routing domain. (Putting them in these distinct locations sim- plifies discovery of translating routers.) The exceptions to this are for intra-domain traffic, where translation can take place at the Pip host (meaning that IP packets come from the Pip host), or, in the case of a packet between two IP hosts without an IP path between them, at whatever Pip routers are closest to the hosts. Pip/IP translating routers are called XRs. 4. If communications is between two IP hosts, and there is an IP infrastructure between them, then the packet remains IP throughout (is not translated to Pip). 5. XRs maintain a pool of IP addresses. (Before you get all excited, note that this is *not* a NAT scheme, or, at least, does not have any of the ugly characteristics of what has become Pip WG, Expires February 1, 1994 [Page 3] INTERNET-DRAFT Pip Transition July 1993 known as NAT schemes [1].) In particular, no modification of checksums are necessary, and the location and choice of XRs are such that the pool of addresses is large enough to not require frequent re-assignment. IP addresses from the pool are mapped to Pip hosts. XRs translate from IP to Pip by indexing the translation table with the destination IP address (which has been assigned from the pool). XRs translate from Pip to IP by indexing the translation table with the source Pip ID. 6. Pip hosts are aware of the pool IP address assigned to them, and use it to calculate the TCP pseudo-header checksum. Thus, the translation at the XR is efficient (on the order of the cost of the IPAE translation). 7. Except for the case of inter-domain packet exchange between two IP hosts across a Pip infra-structure, the assignment of pool IP addresses are made before any internet data packets are transmitted. The assignments are made during DNS lookup. Thus, translating routers generally do not need to make queries them- selves. 2.1. Managing Pools of IP Addresses One concern with the use of pools of IP addresses assigned to Pip hosts is that the dynamics of assignment will result in incorrect translations--that is, IP hosts will remember an assignment after it has been reassigned, and try to use it. Another concern is that the pools will have to be large (to satisfy the first concern), and thus IP address exhaustion will be exacerbated. These concerns are addressed here. As mentioned above, translation generally takes place 1) at the sub- net of the IP host, 2) at the border of the IP domain, and 3) at the border of or within the Pip domain. If translation takes place at the border of the Pip domain, then it means that the backbone infrastructure is still capable of routing IP. The destination IP address, which comes from the XR's pool, will route the packet over the backbone infrastructure to the XR. This IP address must therefore be globally unique. Pip WG, Expires February 1, 1994 [Page 4] INTERNET-DRAFT Pip Transition July 1993 In this case, the XR only needs to maintain translations for the Pip hosts in the Pip domain. Thus, at most, the pool need be only as large as the number of Pip hosts in that domain. With IPAE, the Pip hosts would need an IP address anyway, so stocking the XR with one IP address for every Pip hosts uses no more IP addresses than IPAE. Furthermore, the IP addresses in the pool can be assigned flat (no subnetting). So, in fact, the number of IP addresses needed, even if there is one for every Pip host, is smaller than with IPAE. In addition, it is probably reasonable in many if not most cases for the number of IP addresses in the pool to be smaller than the number of Pip hosts, as usually most hosts in a private network do not directly exchange packets with hosts outside the domain. Thus, in most cases, fewer IP addresses than there are Pip hosts will be required. If the XR is at the IP domain's border or at the IP host's subnet, then the packet will cross the backbone infrastructure as a Pip packet. Intra-domain IP routing will route the packet to the XR. Since the IP packet never reaches the backbone infrastructure, the destination IP address (from the XR's pool) need not be globally unique. Therefore, the pool of IP addresses can come from a reused class A network number. The XR therefore has a pool of over 16,000,000 IP addresses from which to make assignments. These could be subdivided across individual XR's in the IP domain, or each XR in the IP domain could have the full class A, for use on it's attached subnets. At the same time, the number of Pip hosts for which assignments potentially have to be made is large--all Pip hosts. But, with such a large pool, an old assignment could be stale for a long time before it is flushed. (In this case, the memory needed to hold the assign- ments, not the number of assignments available, becomes the bottleneck.) To reiterate, early in transition, when the backbone is still IP, there will be a relatively small number of Pip hosts, and therefore a relatively small number of IP addresses required for XR pools. Later in transition, when the backbone is Pip (though there may still be millions of IP hosts), translation will take place at IP-domain bord- ers or within the IP domain, and XR pool addresses can come from a reused Class A network number. Pip WG, Expires February 1, 1994 [Page 5] INTERNET-DRAFT Pip Transition July 1993 2.2. Phases of Transition There is only one major "phase" in the IPIT transition scheme. That is the point at which IP forwarding is disabled in the provider net- works. Up until that point, IPIT transition takes place piece-meal. For IP forwarding to be disabled in provider networks, all domains must have an XR at the border. By definition, if all provider net- works are able to forward Pip packets, then all domains have an XR at the border--the provider's Pip router is that XR. Thus, once all providers move over to Pip, IP can be turned off in the backbones. There is one clear benefit that results from reaching this phase in the transition. That is, XRs no longer need to have globally unique IP addresses in their pools. As discussed above, an XR pool IP address need only be globally unique when the translation is taking place at the XR bordering the Pip system. Once all IP domains have XRs, there is no longer a need for these globally unique IP addresses. Therefore, all remaining IP addresses can be devoted to true IP hosts. This means that, if at some point we are in danger of IP address depletion, a program of Pip (or some IPng) installation in backbones (or, at least, XR installation at all borders) can be undertaken. While it would be unfortunate to have to "artificially" mandate the installation of any given protocol "before its time", it at least seems feasible to mandate such a thing in provider networks, which represents a small minority of systems globally, and have adequate knowhow for such an installation. Of course, even if this phase of installation is reached, it is pos- sible for address depletion to occur--if too many hosts are installed as IP only. In this case, an IP address re-use must be used. This means either that some IP systems will not be able to communicate globally (only internally), or that a NAT scheme must be employed. Other than the potential need for pushing providers towards Pip, all other installation of Pip can happen naturally. The following para- graphs discuss the requirements for installing Pip systems. In theory, it is possible to install any Pip host any time anywhere in the internet. In practice, however, it is useful to have some amount of Pip infrastructure in place to simplify installation of Pip hosts. Pip WG, Expires February 1, 1994 [Page 6] INTERNET-DRAFT Pip Transition July 1993 2.3. Translation in More Detail Assume that XR has a Pip ID = XPID and a Pip address = XPA. Assume that the XR has assigned an IP address XIP from its pool to a Pip host with ID = HPID, and Pip address = HPA. One or more IP hosts may be exchanging packets with the Pip host using XIP. Assume that the IP addresses of the IP hosts that are exchanging packets are IP1, IP2, and so on. The XR has a translation table that maps XIP into HPID/HPA and maps HPID into XIP. When a packet arrives at XR from IP host with address IP1, the source IP address (sa) is IP1 and the destination IP address (da) is XIP (sa=IP1, da=XIP). XR indexes the translation table with XIP and retrieves HPID and HPA Using this information, it translates this into a Pip packet with a source Pip ID (spid) that contains the IP hosts address IP1, the des- tination Pip ID (dpid) of the Pip host HPID, the source Pip address (spa) of itself XPA, and the destination Pip Address (dpa) of the Pip host HPA (spid = IP1, dpid = HPID, spa = XPA, dpa = HPA). Thus, the translation is <sa=IP1, da=XIP> -X-> <spid=IP1, dpid=HPID, spa=XPA, dpa=HPA> where the symbol -X-> means translation. Note that the IP host's address IP1 never entered into the lookup process. It was just copied from the source IP address into the source Pip ID. Thus, a packet from IP2 to the same Pip host would use the same translation table entry: <sa=IP2, da=XIP> -X-> <spid=IP2, dpid=HPID, spa=XPA, dpa=HPA> When a packet from the Pip host back to IP1 is received at XR, it uses the Pip host's Pip ID HPID to index the translation table and retrieve XIP. Thus, the reverse translation is: <spid=IP1, dpid=HPID, spa=XPA, dpa=HPA> -X-> <sa=IP1, da=XIP> Note that even though the Pip host does not transmit XIP in its packet, it knows that XIP is the pool IP address assigned to it, and uses XIP (and IP1) to calculate the TCP pseudo-header checksum. Pip WG, Expires February 1, 1994 [Page 7] INTERNET-DRAFT Pip Transition July 1993 2.4. Creating the Assignment In this section, we discuss how the assignment XIP<->HPID is made and communicated to the Pip host. We also discuss how the translating router XR is discovered. We are interested in the following cases: Initiating Responding Host (IH) Host (RH) Scope IH DNS RH DNS ---------- --------- ----- ------ ------ 1. IP-only Pip Inter-domain IP-only Pip 2. Pip IP-only Inter-domain Pip IP-only 3. IP-only Pip Inter or Intra-domain Pip Pip 4. Pip IP-only Inter or Intra-domain Pip Pip 5. IP-only IP-only Inter-domain N/A N/A 6. IP-only IP-only Intra-domain N/A N/A By initiating host, we mean the host that initiates the exchange of packets (that is, first contacts DNS and sends the first IP/Pip packet). Note that cases 5 and 6 imply two IP hosts communicating across a Pip backbone infrastructure. We assume that any domain with a Pip host has updated DNS. Any domain with no Pip hosts may or may not have an updated DNS. If it does, then we assume that it also has a translating router (XR) at its border. Note that therefore Cases 1 and 2 don't apply to the intra-domain case (where DNS must be Pip if any host is Pip). Note that in all cases but 5, the Pip DNS systems discover XRs, thus offloading the burden of XR discovery from XRs. Only case 5 requires that an XR does an inverse DNS lookup to discover an XR. (Compared with IPAE, where every new packet exchange from IP to IPng requires such a lookup by the XR.) Below we discuss each case. 2.4.1. Case 1. Here, an IP host is initiating and a Pip host is responding. Only the Pip host has Pip DNS. Pip WG, Expires February 1, 1994 [Page 8] INTERNET-DRAFT Pip Transition July 1993 a. The initiating IP host I-IP-H queries its local DNS server I- IP-DNS. b. I-IP-DNS queries the Pip host's DNS server R-Pip-DNS (assuming that I-IP-DNS is not also the DNS server for the responding host R-Pip-DNS). Based on the nature of the query, R-Pip-DNS knows the initiating host I-IP-H to be IP-only [3]. c. Null step here to sync with the next section. Please ignore. d. The R-Pip-DNS server must determine the translating router XR for this exchange. At this point, R-Pip-DNS knows that I-IP-H's domain has no XR's internally (or else it would have a Pip DNS), but it doesn't know if there is an XR at the border of I-IP-H's domain or not. R-Pip-DNS does not know the name or IP address of I-IP-H. It only knows the IP address of I-IP-H's DNS server I-IP-DNS. Using the IP address of I-IP-DNS as the inverse domain name, R-Pip-DNS makes an inverse query to the set of sys- tems that have been established to handle these inverse queries. e. If there are one or more XRs at the border of I-IP-H's private domain, then the inverse query returns the Pip ID and Pip addresses of the XRs. If there isn't an XR at the border of I- IP-H's private domain, then the inverse query returns null. f. If the previous step returned null, then an XR bordering the Pip host's private domain (or inside the Pip host's private domain, if none have been installed at the border) is selected as the XR for this exchange. If there are multiple XRs at the local border, R-Pip-DNS chooses among them to be the XR for the exchange. This choice may be based on knowledge of the host's or domain's policies, or may be a pre-set preference, or may be random. (These XRs are known through static configuration of R-Pip-DNS.) If the inverse query did not return null, then one of the XRs returned in the inverse query are selected. g. The R-Pip-DNS now queries the XR for an assignment of a Pool address XPA to the Pip host R-Pip-H. (Note that if the XR is local to the Pip host's domain, this assignment may very well have already been made. Never-the-less, the query is made.) The query contains the Pip ID of R-Pip-H, plus other information from DNS such as the Pip addresses, mobile host server, and so on [3]. h. The XR makes the assignment XPA, and returns it to R-Pip-DNS. Pip WG, Expires February 1, 1994 [Page 9] INTERNET-DRAFT Pip Transition July 1993 i. R-Pip-DNS returns assigned IP address XPA to I-IP-DNS, which in turn returns it to the IP host I-IP-H. (The Time-to-Live in the response should be quite low, perhaps even 0.) j. The I-IP-H sends an IP packet with it's IP address IPA as the source address, and XPA as the destination address. k. XR receives this packets, looks up the assignment using XPA, retrieves the information about R-Pip-H, and creates a Pip header to send to R-Pip-H. The source Pip ID of the header con- tains IPA (in an Pip ID format that indicates that the host is an IP-only host). The destination Pip ID is R-Pip-H's Pip ID. The destination Pip address is R-Pip-H's Pip address. The source Pip address is that of XR. Finally, there is an option added that contains XPA. This is necessary for the Pip host to be able to compute the pseudo-header checksum. 2.4.2. Case 2. Here, a Pip host is initiating and an IP host is responding. Only the Pip host has Pip DNS. a. The initiating Pip host I-Pip-H queries its local DNS server I- Pip-DNS. b. I-Pip-DNS queries the IP host's DNS server R-IP-DNS. (It may have been necessary for I-Pip-DNS to first determine that R-IP- DNS is in fact an IP-only DNS server. This is part of DNS tran- sition [3].) c. I-Pip-DNS receives the IP address IPA of the IP host R-IP-H in the answer. d. I-Pip-DNS must determine the translating router XR for this exchange. Using IPA as the inverse domain name, I-Pip-DNS makes an inverse query to the set of systems that have been esta- blished to handle these inverse queries. e-f. These steps are the same in the previous section (but with I and R reversed). Pip WG, Expires February 1, 1994 [Page 10] INTERNET-DRAFT Pip Transition July 1993 g. I-Pip-DNS returns the information about the XRs, along with R- IP-H's IP address IPA, to I-Pip-H. h. I-Pip-H determines which of the XRs is appropriate for this packet exchange (see [4] for a description of how this is done). i. I-Pip-H now queries the selected XR for an assignment of a Pool address XPA for itself. j. The XR makes the assignment XPA, and returns it to I-Pip-H. k. I-Pip-H sends a Pip packet with a destination Pip ID containing IPA (in an Pip ID format that indicates that the host is an IP- only host). The source Pip ID is that of I-Pip-H. The destina- tion Pip address is that of XR. The source Pip address is that of I-Pip-H. The pseudo-header checksum is calculated using IPA and XPA. l. XR receives this packets, looks up the assignment using the Pip host's Pip ID, retrieves the information about R-IP-H, and creates a Pip header to send to R-IP-H. The source IP address is XPA, and the destination IP address is IPA. 2.4.3. Case 3. Here, an IP host is initiating and a Pip host is responding. Both of the host's domains have Pip DNS. a. The initiating IP host I-IP-H queries its local DNS server I- Pip-DNS. b. I-Pip-DNS queries R-Pip-H's server R-Pip-DNS. Because of the nature of the query, R-Pip-DNS knows that I-Pip-DNS is a Pip capable DNS machine, and that either 1) I-IP-H is in the same domain as R-Pip-H, or 2) I-IP-H is in another domain, and it's domain has an XR (either at its border or internally). c. R-Pip-DNS returns the Pip information (Pip ID, Pip addresses, etc.) of R-Pip-H to I-Pip-DNS. d. I-Pip-DNS determines if R-Pip-H is intra- or inter-domain by comparing R-Pip-H's Pip address against a local table indicating Pip WG, Expires February 1, 1994 [Page 11] INTERNET-DRAFT Pip Transition July 1993 which Pip address prefixes are intra-domain. This table must be maintained by hand (though the consequence of not maintaining it properly is a non-optimal path rather than failure to communi- cate). e. I-Pip-DNS knows that the order of preference for choosing the XR is 1) choose one on I-IP-H's subnet, 2) choose the XR at I-IP- H's domain's border (only if inter-domain), 3) choose the XR on R-Pip-H's subnet (only if intra-domain), and 4) let R-Pip-H be the XR (that is, R-Pip-H transmits and receives IP packets, again, only for intra-domain). (Note that if option 4 happens, the Pip host loses the ability to be mobile.) f. I-Pip-DNS must therefore first determine if there is an XR on the subnet of the IP host or not. To do this, I-Pip-DNS looks in its local database, which has a listing of all IP subnets with Pip routers on them. If an entry exists for I-IP-H's sub- net, then the XR on that subnet is chosen (choice 1 in step e). If not, but the communications is inter-domain, then the border XR of I-IP-H's domain is used (choice 2 of step e). If the com- munications is intra-domain, I-Pip-DNS determines if there is an XR attached to R-Pip-H's subnet. This is done using the same table accessed earlier in this step (except with the Pip Address as the index instead of the IP address). (Except for very early in transition, there will usually be an XR on R-Pip-H's subnet.) If there isn't, then R-Pip-H must be the XR for itself. (This will be the case where there is only a single host, or a small number of hosts, and no router, on a given subnet. It means that the first Pip system installed on a subnet must be given a pool of IP addresses.) g. I-Pip-DNS now queries the XR for an assignment of a Pool address XPA to the Pip host R-Pip-H. h. The XR makes the assignment, and returns it to I-Pip-DNS. i. I-Pip-DNS returns assigned IP address XPA to the IP host I-IP-H. j-k. These steps are the same as for Case 1. 2.4.4. Case 4. Here, a Pip host is initiating and an IP host is responding. Both Pip WG, Expires February 1, 1994 [Page 12] INTERNET-DRAFT Pip Transition July 1993 hosts' domains have Pip DNS. a. The initiating Pip host I-Pip-H queries its local DNS server I- Pip-DNS. b. I-Pip-DNS queries the IP host's DNS server R-Pip-DNS. c. R-Pip-DNS determines if I-Pip-H is intra- or inter-domain. To do this, R-Pip-DNS indexes the table discussed in step d of Case 3, using the Pip address or IP address (whatever is known) of I-Pip-DNS. (The assumption here is that I-IP-H is in the same domain as I-Pip-DNS.) d. At this point, R-Pip-DNS must determine which XR should handle this communications. This is done in the same way as done by I-Pip-DNS in step f of Case 3. e. Having determined the appropriate XRs, R-Pip-DNS returns infor- mation about the XRs and the IP address of the IP host R-IP-H to I-Pip-DNS, which forwards it on to I-Pip-H. f. (Null step here to sync with Case 2. Please ignore.) h-l. These steps are the same as for Case 2. 2.4.5. Case 5. Here, an IP host is initiating and an IP host is responding. The two IP hosts are in different domains. It is irrelevant if DNS is Pip or IP. a. The initiating IP host I-IP-H queries its local DNS server I- DNS. b. I-DNS queries the responding IP host's DNS server R-DNS, receives the IP address of the responding IP host R-IP-H, and returns it to I-IP-H. (Note that IP addresses must be globally unique for this to work. At the point where IP addresses are not globally unique, interdomain communications between IP-only hosts might not be possible.) Pip WG, Expires February 1, 1994 [Page 13] INTERNET-DRAFT Pip Transition July 1993 c. I-IP-H transmits a packet with its IP address as the source address, and R-IP-H's IP address as the destination address. d. This packet reaches a translating router I-XR, either at the border of I-IP-H's domain if inter-domain, or within the domain, probably at I-IP-H's subnet router, otherwise. (If the infras- tructure is IP, then the packet won't reach a translating router and will be sent IP end to end.) e. I-XR first determines if the packet is intra- or inter-domain. Within a domain, each Pip router knows the mapping between each Pip subnet address prefix and its corresponding IP subnet number. This information is carried by the intra-domain routing protocol. I-XR indexes the database carrying this information. For this case, we assume inter-domain. f. Because it is interdomain, I-XR must determine the Pip address of the translating router R-XR, either at the border of R-IP-H's domain, or on R-IP-H's subnet. This is done using the same inverse query that was used for Cases 1 and 2, only here I-XR initiates the query instead of <I or R>-Pip-DNS. Using the IP address of I-IP-H as the inverse domain name, I-XR makes an inverse query to the set of systems that have been established to handle these inverse queries. g. The inverse query returns the Pip ID and Pip addresses of R-XR (for this case, there must be an XR at the border or within R- IP-H's private domain). I-XR creates a data base entry relating the IP address of R-IP-H with the Pip information for R-XR. This is used to translate this and subsequent packets from I- IP-H into Pip packets. h. I-XR translates the IP packet into a Pip packet destined for R- XR. The source Pip ID of the header contains the IP address of I-IP-H (in an Pip ID format that indicates that the host is an IP-only host). The destination Pip ID contains the IP address of R-IP-H. The destination Pip address is R-XR's Pip address. The source Pip address is that of I-XR. i. When R-XR receives this packet, it creates a data base entry relating the IP address of I-IP-H (taken from the source Pip ID) with the Pip address of I-XR. This entry is used to translate IP packets from R-IP-H. Note that subsequent packets from I- IP-H and R-IP-H may go through different XRs (if there are more than one at the border). In this case, the XRs receiving the Pip WG, Expires February 1, 1994 [Page 14] INTERNET-DRAFT Pip Transition July 1993 packets make inverse queries as described above. 2.4.6. Case 6. Here, an IP host is initiating and an IP host is responding. The two IP hosts are in the same domain. It is irrelevant if DNS is Pip or IP. a-e. These steps are the same as for Case 5, except with the outcome that the two IP hosts are determined to be intra-domain. f. Because it is intra-domain, I-XR does not need to determine the Pip address of the translating router R-XR. Rather, since it knows the mapping between R-IP-H's subnet number and the Pip address of R-IP-H's subnet, it can generate a Pip header algo- rithmically. I-XR translates the IP packet into a Pip packet destined towards R-XR. The source Pip ID of the header contains the IP address of I-IP-H (in an Pip ID format that indicates that the host is an IP-only host). The destination Pip ID con- tains the IP address of R-IP-H. The destination Pip address is the Pip address of the subnet that corresponds to R-IP-H's IP subnet address. The source Pip address is that of I-XR. g. This packet will travel towards R-IP-H until it reaches an XR that must translate the packet back into IP. The reverse trans- lation is simple. The source and destination IP addresses are copied over from the source and destination Pip IDs. The resulting IP packet is routed towards R-IP-H. h. Packets returning from R-IP-H to I-IP-H execute steps f and g. 2.5. Inverse Lookup Infrastructure On several occasions, it is necessary for a DNS system or an XR to do an inverse query on IP address searching for an XR for the destina- tion IP host. These queries are handled by a hierarchy of DNS servers installed for this purpose. At the top of the hierarchy are a relatively small set (perhaps 10 or so) of root servers. These root servers will be authoritative for Pip WG, Expires February 1, 1994 [Page 15] INTERNET-DRAFT Pip Transition July 1993 private IP domains that have not installed an Pip systems, but that have an XR at the border. By authoritative, we mean that they will hold the actual database entries that map IP addr/mask to XR informa- tion. The root servers will contain pointers to lower level servers for those private domains that have installed some Pip systems. These lower level servers will be authoritative for the XRs in their domain. All servers will be capable of being both authoritative and pointing to lower level servers. In addition, the entries will be keyed by maskless IP addr/masks. Therefore, the number of hierarchy levels of inverse query DNS servers is entirely determined by configuration. As such, it will be possible in the future to add a layer of hierar- chy below the root servers if they prove to be a bottleneck. 2.6. Configuration Requirements Pip transition will start with a "seed" Pip backbone (the Pbone). The Pbone will consist of a small number (10 to 20) of Pip routers installed around the internet--preferably in places where the most policy routing control can be leveraged, for instance, at DMZs. (DMZ meaning so-called De-militarized zone, such as a FIX or a CIX.) There will also be a seed system of inverse Pip-DNS lookup systems. Ini- tially, these are likely to be the same machines as the Pbone routers. As the Pbone routers (sparcs) are replaced by "real" Pip routers, these systems can be dedicated to the inverse lookup func- tion. When the first host is installed in a private domain, Pip DNS must also be installed, and preferably Pip routers should be installed at the borders of the domain. If Pip routers are not installed at the borders, then either a Pip router internal to the domain, or a router outside the domain, must be used for translation. Using XRs not at the border can weaken or prevent provider selection, and can result in non-optimal paths (because the packet must be routed via the XR). When Pip DNS is installed, it must be configured with the addresses (IP or Pip) of higher level inverse DNS lookup servers (along with all the other usual DNS configuration information). It must also be configured with IP addr/masks showing which IP address prefixes are within its private domain. When the first Pip system is installed on a subnet, it should act as Pip WG, Expires February 1, 1994 [Page 16] INTERNET-DRAFT Pip Transition July 1993 a router, even though it may also be serving as a host. As a router, it must be configured with information about its neighbor routers, either those on directly connected subnets or those reachable through IP, including the border routers. (Note that it is possible to install a single host on a subnet and configure it with non-attached routers over IP. This will likely be common very early in transi- tion, especially during initial experimentation. Over time, however, this should be the exception rather than the rule.) As the first router on a subnet, it must also be configured with a pool of IP addresses to handle Pip hosts on its attached subnets. Note that the addresses in the pool are only used for intra-domain communications. (Generally, border XRs handle translation for inter-domain packets, though it is possible for an internal Pip router to be the XR for inter-domain traffic before a border XR is installed.) DNS must also be updated to indicate that a Pip router has been installed on the subnet, with the mapping between Pip subnet address and IP subnet address. When an XR is installed at the border, it's neighbor routers must be configured. It must also be configured with two pools of IP addresses, one to serve IP hosts in the private domain (this can be a re-used class A), and one to serve Pip hosts in the private domain (these must be globally unique). Local Pip DNS, if it exists, must be updated to have knowledge of the XR, and to know which IP prefixes it serves. Root DNS inverse-lookup servers must be updated to know that the local DNS handles these IP prefixes if local Pip DNS exists, or must be configured with direct information about the border XR otherwise. References [1] Dave Crocker, Bob Hinden, "IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP", Internet Draft, Nov 1992. [2] Kjeld Borch Egevang, Paul Francis, "The IP Network Address Translator (NAT)", Internet Draft, May 1993 [3] Thomson, Francis, "Use of DNS with Pip", Internet-Draft [4] Francis, "Pip Host Operation", Internet-Draft Pip WG, Expires February 1, 1994 [Page 17]